Costing Safety Critical Software

The views expressed in this paper are the views of the author and not necessarily those of the MOD. This paper will focus on the COSTS associated with validation of Safety Critical Software and will suggest some considerations for the way forward. The costs of safety analysis of Software are not straightforward to estimate. The extent of errors in the software requiring correction cannot be predicted in advance of analysis, and if white box evidence is lacking (in the case of COTS or SOUP), cannot even reliably be extrapolated partway through the analysis process from early results. Losing control of the fault fixing process escalates costs and increases the likelihood of safety implications. The completion criteria of the safety analysis process are not objective but depend on a judgment by the assessors. This judgment can not be made in advance of completion. Evidence to support the certification of Software will in general belong to suppliers who may be reluctant to release it. Its cost will therefore be a matter of negotiation, and, because of commercial factors, may bear little relation to the cost of generating it in the first place. The ease of application of many methods, particularly white box approaches such as static analysis likely to be favored by assessors, is sensitive to the quality and type of evidence available. Introduction: Within the Smart Acquisition Cycle, the pursuit of dependable high integrity software presents major hurdles to overcome. Military systems are becoming more and more dependent upon the correct functioning of increasingly complex software. Currently MOD faces a serious problem with software intensive systems and faces unbounded risk on software development and support with respect to cost, performance and schedule. Irrespective of whether Software-based systems are built from SOUP, COTS, BESPOKE code or a combination, they remain vulnerable because they almost invariably contain design faults in their software (and perhaps in their hardware) that are triggered when the computer system receives inappropriate inputs (the inputs may not be inappropriate but could be unexpected or not designed for). Many of these faults will have been present from inception (ie from incorrect specification or design) , and others will have been introduced during any changes that have taken place throughout the system lifetime. The reality is that even programs of surprisingly modest size and complexity must be assumed to contain design faults. It is the responsibility of the designer, having made every effort to minimise the number of residual faults, to ensure that any remaining undetected faults do not have an unacceptable effect upon other systems with which the computer system interacts: in particular, that they do not compromise the safety of the wider system. They should be able to demonstrate the fact that residual faults do not adversely affect the safety of the system, by means of proof, analysis results or through test results.